5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
- Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 2-2: Data Dictionary Concepts

Tracking Processing Requirements


The data dictionary input processes track specific types of modifications that, when they occur, require processing of the dictionary (or selected parts of it). They do so by maintaining various date/time stamps, and by comparing the date/time of unprocessed specifications with the corresponding processed formats.

By tracking those situations that require processing of a dictionary or dictionary component, APPX can:

Enhance performance by limiting the magnitude of data dictionary processing.

Eliminate error by removing the possibility that other components within APPX will access obsolete data specifications.

In general, the situations that give rise to a processing requirement are the following:

Domains require processing after they are added to the dictionary and whenever their specifications are modified, including modification of an associated validation or token table. If a domain requires processing, all fields that reference it also require processing. If a domain is deleted from the dictionary, any remaining fields that reference the domain must be modified and processed.

Files require processing after they are added to the dictionary, and whenever their specifications are modified. In addition, a file must be processed whenever fields are added or deleted, or a field specification is modified. If a file is deleted from the dictionary, its fields and element records are automatically deleted. The dictionary does not have to be processed.

Fields are processed based upon a requirement maintained at the file level.If the specifications for any field change, the file and all its fields must be processed. If one or more fields are deleted from the dictionary, the file must be processed.

Work fields must be processed whenever a work field is added or deleted, and whenever a specification for any work field is modified. For this purpose, work fields are considered to reside in a single work fields file, with the processing requirement maintained at the file and field level. If any work field requires processing, all work fields are processed. To improve performance, however, individual work fields that do not require processing on their own merit are simply verified against the current element record.

Application Design Manual                                         "Powered by Appx Software"

134

©2006 By APPX Software, Inc. All Rights Reserved